真正的存活检测必须深入业务层，用HTTP探针模拟真实调用，结合状态码、响应时间、内容特征综合判断；需用HEAD请求访问专用健康接口（如/health），该接口不依赖外部资源、不触发耗时逻辑、返回固定JSON结构且状态码限200–399；超时设为P95响应时间1.5倍（≤10秒），间隔≥2倍超时，重试3次；启动慢服务需配置宽限期（60–120秒）；内容校验应检查Content-Type、status字段值及timestamp新鲜度；探测结果必须驱动日志、告警、重启或服务下线等动作。
守护进程做HTTP接口存活检测，关键不是“能不能发请求”，而是“怎么判断才算真活着”。光看进程在不在、端口通不通远远不够——服务可能卡在加载模型、死锁、或响应超时，但PID和TCP连接都正常。真正的存活检测必须深入业务层，用HTTP探针模拟真实调用，结合状态码、响应时间、内容特征做综合判断。
选对探测方式：HEAD比GET更轻量，/health比/更可靠
优先使用HEAD请求而非GET，避免传输完整响应体，降低网络与服务端开销；路径必须是专为健康检查设计的独立接口（如/health或/readyz），不能复用业务路径（如/api/v1/users）。这个接口应满足：
- 不依赖外部资源（数据库、缓存、下游API）
- 不触发耗时逻辑（如模型加载、文件读写）
- 返回固定结构JSON，含status: "ok"及可选的timestamp字段
- HTTP状态码严格限定在200–399区间，4xx/5xx一律视为不健康
设置合理超时与重试：避免误判，也别放任故障
一次失败不等于宕机，连续失败也不等于永久不可用。需平衡灵敏性与稳定性：
- timeout设为服务P95响应时间的1.5倍，但不超过10秒（如实际平均响应300ms，timeout建议5s）
- interval至少是timeout的2倍，防止探测堆积（如timeout=5s，则interval≥10s）
- retries设为3次，既过滤瞬时抖动，又不拖延故障发现
- 对启动慢的服务（如PyTorch大模型），务必配置start-period（Docker）或initialDelaySeconds（K8s），给予60–120秒宽限期
状态判定不止看状态码：加一层内容校验更稳妥
仅靠HTTP状态码有风险：服务可能返回200但内容为空、格式错乱，或返回伪造的静态HTML。建议在基础探测上叠加简单内容验证：
- 检查响应头Content-Type是否为application/json
- 解析响应体，确认存在status字段且值为"ok"
- 验证timestamp字段是否在最近30秒内（防缓存或僵尸响应）
- 用curl时可组合：curl -f -s http://localhost:8080/health | jq -e '.status == "ok" and (.timestamp | now - . > 30)'
探测结果必须驱动动作：只检查不处理等于没检查
健康检查本身没有价值，价值在于它触发的后续行为。守护进程收到“不健康”信号后，应立即执行明确动作：
- 记录带时间戳的失败日志，包含URL、状态码、响应体摘要、耗时
- 若连续失败达阈值，执行预设恢复操作：重启目标进程、发送告警Webhook、调用运维API下线节点
- 恢复后主动触发一次验证，确认服务真正可用再标记为healthy
- 将当前状态同步到外部系统（如Consul健康注册、Prometheus指标暴露）
