健康检查指标：系统、应用、业务

做健康检查，第一个要问自己的问题是：我到底要检查什么？

很多人上来就盯CPU、内存，觉得这些数字正常系统就没问题。其实这是个错觉。我见过一个项目，CPU一直维持在30%以下，但用户已经卡得骂娘了——后来发现是数据库连接池耗尽，应用层在排队等连接，系统层却毫无压力。所以指标必须分层，而且得串联起来看。

我个人习惯把健康检查指标分成三层：系统层、应用层和业务层。下面一个一个说。

系统指标

系统指标是地基。地基不稳，上面再漂亮也没用。但我得提醒一句：单个系统指标“正常”不代表真正常，得看趋势和组合。

• CPU：不只是看使用率，还要看iowait和steal。我曾经有个线上事故，CPU使用率才60%，但iowait占了40%——磁盘扛不住了，应用响应时间直接翻倍。
• 内存：注意区分used和cached/buffers。我见过运维兄弟一看内存80%就报警，其实大部分是文件缓存。真正危险的是available低于10%且swap开始涨。
• 磁盘：空间监控是基础，但IO延迟才是关键。我个人习惯把await > 30ms作为警告线，超过100ms必须处理。
• 网络：带宽利用率、丢包率、TCP重传率。重传率超过1%基本说明网络或者对端服务有问题。

应用指标

系统指标都OK，不代表应用跑得稳。应用指标才是业务方真正感知到的。我一般看三个核心：响应时间、错误率、吞吐量。

• 响应时间：关注P99而非平均值。平均值会被拖低，P99才能反映真实体验。我之前一个支付接口，平均响应时间200ms看着挺好，P99却到了5秒——业务方投诉时我才发现缓存穿透问题。
• 错误率：HTTP 5xx比例、业务错误码比例。比如登录接口错误率突然从0.1%涨到2%，可能是认证服务挂了。
• 吞吐量：QPS / TPS。吞吐突然下降往往是资源瓶颈或依赖服务限流。判断方式是：吞吐下降 + 响应时间上升 = 有问题；吞吐下降 + 响应时间下降 = 可能流量减少。

# 用一个简单的curl脚本做应用健康检查
# 检查响应时间 < 200ms，状态码为200
start=$(date +%s%N)
response=$(curl -s -o /dev/null -w "%{http_code}" http://api.example.com/health)
end=$(date +%s%N)
duration=$(( (end - start) / 1000000 ))  # 转毫秒

if [ $response -eq 200 ] && [ $duration -lt 200 ]; then
    echo "应用健康"
else
    echo "响应码=$response 耗时=${duration}ms"
fi

业务指标

这是最容易被忽略的一层。系统、应用都正常，但用户没完成下单、支付、注册——那健康检查就是个笑话。

业务指标应该由产品经理和业务方共同定义。举个例子：电商系统的健康度不能只看系统CPU，更要看订单创建成功率、支付回调成功率、购物车加购转化率。我曾经做过一次容灾演练，所有系统指标绿得发亮，但业务指标掉了一半——因为缓存集群闪断导致库存扣减延迟，用户下单后显示“库存不足”但实际有货。

常见的业务指标举例：

• 登录成功率
• 下单完成率
• 支付成功率
• 核心业务漏斗转化率（如从搜索到加购到支付）
• 关键报表生成耗时