误报比漏报更难收拾
误报的代价不只是多出一条告警，而是团队逐步开始忽略告警本身。频率与误报的关系是：频率越高，单次抖动被判为故障的概率越大；频率越低，真实故障被发现得越晚。控制误报的核心手段是连续失败判定、超时留足余量、探测错峰，并区分启动期与稳态期。
基本信息
| 判定方式 | 连续 N 次失败才判定不健康，恢复亦需连续成功 |
|---|---|
| 参数构成 | 探测间隔、单次超时、失败阈值、成功阈值 |
| 启动期处理 | 独立启动探针或延迟首次探测 |
| 抖动来源 | 网络瞬断、运行时停顿、下游偶发慢响应 |
| 调参依据 | 误报比例与人工确认结果，而非主观感觉 |
典型使用场景
- 网络波动环境：用连续失败判定抵消单次丢包造成的瞬时误判
- 冷启动应用：启动期资源争抢严重，需要独立启动探针或延迟首检
- 存在定期停顿的运行时：垃圾回收或后台任务造成秒级停顿，超时需留余量
- 大规模集群：探测加抖动，避免所有目标在同一秒集中探测
- 参数治理：统计误报比例与人工确认结果，定期回头修正阈值
常见误报来源与对策
| 误报来源 | 表现 | 对策 |
|---|---|---|
| 单次网络抖动 | 孤立的一次超时 | 连续失败才判定不健康 |
| 启动期未就绪 | 刚启动即被判失败 | 启动探针或延迟首检 |
| 运行时停顿 | 周期性短超时 | 超时留余量并适度降频 |
| 下游偶发慢 | 上游探针连带失败 | 探测内容与依赖解耦 |
探针参数配合要点
探针参数配合要点
# 连续失败判定：抵消单次抖动，避免一次丢包就摘除实例
failureThreshold: 3 # 连续 3 次失败才判不健康
successThreshold: 1 # 恢复只需 1 次成功，缩短恢复延迟
periodSeconds: 10 # 探测间隔
timeoutSeconds: 3 # 超时留余量，覆盖运行时停顿
# 启动期用独立探针，避免把初始化耗时算作故障
startupProbe:
failureThreshold: 30 # 启动期允许更多次失败间隔、超时与失败阈值共同决定检测延迟：最坏情况下从故障发生到判定大约为间隔乘失败阈值再加超时。要缩短发现时间，必须同时压缩间隔与失败阈值，代价是开销与误报概率同步上升。
高频探测在共享依赖上会形成周期性尖峰。数千目标同频探测时，即使单次开销极小，叠加后仍可能触发被检端限流，把探测推进误报与重试的循环。