两个视角回答不同问题
系统级检查看主机与进程是否正常：资源水位、磁盘、端口监听、进程状态、内核与服务状态。应用级检查看业务功能是否可用：接口能否正确返回、依赖是否连通、关键事务能否完成。两者回答的问题不同，系统级正常不代表应用可用，应用级失败也未必源于主机。
基本信息
| 系统级视角 | 主机资源、进程与端口、服务与内核状态 |
|---|---|
| 应用级视角 | 接口语义、依赖连通性、关键事务结果 |
| 典型错配 | 主机指标全绿但接口已持续返回错误 |
| 归属划分 | 系统级归基础设施团队，应用级归应用团队 |
| 联动方式 | 两级并存，定位时互为上下层证据 |
典型使用场景
- 主机巡检：判断资源水位与进程存活，适合大批量且语义简单的目标
- 接口探活：判断服务能否正确处理请求，可覆盖依赖与配置问题
- 分层排障：接口异常时先看系统级指标，快速区分资源不足与逻辑错误
- 容量规划：系统级检查结果用于资源池调度与扩容决策
- 变更验证：应用发布后跑应用级检查，系统变更后跑系统级检查
两类检查的分工
| 维度 | 关注对象 | 典型判据 |
|---|---|---|
| 系统级 | 主机、进程、内核 | 资源水位、进程状态、端口监听 |
| 应用级 | 服务接口、依赖组件 | 状态码、返回内容、响应时间 |
| 共同盲区 | 跨服务调用链路 | 需依赖链检查补齐 |
| 责任归属 | 基础设施团队 | 应用团队对业务结果负责 |
两级检查并列使用
两级检查并列使用
# 系统级：进程与端口是应用可用的必要条件，不是充分条件
systemctl is-active app.service || echo system-level-down
ss -lntp | grep -q :8080 || echo port-not-listening
# 应用级：请求真实接口并校验内容，覆盖依赖与配置错误
code=$(curl -fsS -o /tmp/h.txt -w %{http_code} http://127.0.0.1:8080/healthz)
[ $code = 200 ] || echo app-level-degraded
grep -q ok /tmp/h.txt || echo unexpected-response-body系统级检查发现不了连接池耗尽、缓存不可用、下游超时这类应用问题；应用级检查也解释不了根因，例如内存不足或磁盘写满。两者并存才能既发现故障又支撑定位。
只做系统级检查会制造虚假健康：进程还在、端口仍在监听，但请求全部失败。用进程存活探测代替业务探测，会把长时间的应用级故障报告成一切正常。