深与浅的取舍
检查越深越容易发现真实故障，但每次探测都要消耗被检端的 CPU、连接与 I/O。平衡点取决于探测频率、目标数量与被检端承载能力：单机探针每几秒发一次轻量请求没有问题，同样频率跑一次全表统计就会把数据库拖垮。因此深度应与频率反向配置，而不是全局统一。
基本信息
| 浅层检查 | 进程、端口、轻量接口，耗时毫秒级 |
|---|---|
| 中层检查 | 接口语义校验、依赖连通性，耗时百毫秒级 |
| 深层检查 | 数据一致性、端到端事务校验，耗时秒级以上 |
| 频率约束 | 单次开销乘频率乘目标数等于检查体系总负载 |
| 分层策略 | 浅层高频、深层低频，分别对应不同处置动作 |
典型使用场景
- 高频探针：只做浅层检查，用于快速发现进程退出与端口不可达
- 定时深度检查：分钟或小时级运行语义与数据校验，用于发现缓慢劣化
- 容量受限目标：数据库与存储压低探测频率，改用指标侧采集
- 大规模集群：按目标数量反推单目标频率，避免探测流量超过业务流量
- 发布与故障期间：提高浅层频率、暂停深层检查，避免与应用争抢资源
检查深度与代价对照
| 层级 | 典型动作 | 适用频率 |
|---|---|---|
| 浅层 | 进程存活、端口连通 | 秒级到十秒级 |
| 中层 | 接口语义、依赖连通 | 十秒级到分钟级 |
| 深层 | 数据一致性、端到端事务 | 分钟级到小时级 |
| 极深 | 全量扫描、容量重算 | 业务低谷按周期执行 |
分层频率配置示例
分层频率配置示例
# 浅层高频：只判断接口可响应，开销极小
livenessProbe:
httpGet: {path: /healthz, port: 8080}
periodSeconds: 10 # 高频但极轻量
timeoutSeconds: 2
# 深层低频：校验依赖与数据一致性，用降频抵消单次高开销
readinessProbe:
exec: {command: [/opt/check/deep-check.sh]}
periodSeconds: 60 # 降频执行，避免打垮被检端
timeoutSeconds: 10判断开销是否可以接受，可用总预算衡量：单目标单次开销乘探测频率再乘目标数，得到检查体系自身占用的资源。当该数字接近业务峰值的可观比例时，检查已从保障手段变成负载来源。
深层检查往往需要真实查询，会触碰共享资源。多个目标同时执行时容易在依赖组件上形成尖峰，因此深层检查必须加抖动错峰，并避开备份与批处理窗口。