分层的思路
监控分层把对象按距离用户的远近排列：基础设施、中间件、应用、业务与端到端体验。不同层级的指标用途不同——越靠近业务的越适合做告警，越靠近基础设施的越适合做定位与容量分析。
分层的价值在于下钻
从现象逐级下钻是分层最大的价值：业务指标报警后看应用接口，再看中间件与主机，排查路径固定下来就不必每次重新摸索。前提是各层使用统一的服务与实例标识，否则层与层之间无法衔接。
基本信息
| 层级划分 | 基础设施、中间件、应用、业务、体验 |
|---|---|
| 告警倾向 | 越靠近业务越适合做通知 |
| 定位倾向 | 越靠近基础设施越适合做容量与根因分析 |
| 衔接前提 | 统一的服务与实例标识 |
典型使用场景
- 业务监控：下单成功率与支付转化，直接对应用户能否完成交易
- 应用监控：接口的请求量、错误率与耗时
- 中间件监控：连接数、慢查询、队列积压
- 基础设施监控：CPU、内存、磁盘、网络与可用性
- 体验监控：拨测与真实用户指标，验证端到端可用
分层看板的常用指标组合
分层看板的常用指标组合
up{job=~"node|mysql|redis"} # 基础设施可用性
mysql_global_status_threads_connected # 中间件会话数
sum by (service) (rate(http_requests_total{code=~"5.."}[5m])) # 应用错误
sum(rate(orders_created_total[5m]))
/ sum(rate(orders_submitted_total[5m])) # 业务成功率分层与关注点
| 层级 | 典型对象 | 典型指标 |
|---|---|---|
| 基础设施 | 主机、网络、存储 | CPU、内存、磁盘、网络、可用性 |
| 中间件 | 数据库、缓存、消息队列 | 连接数、慢查询、队列积压 |
| 应用 | 服务、接口、依赖 | 请求量、错误率、耗时 |
| 业务 | 订单、支付、注册 | 成功率、转化率、投诉量 |
| 体验 | 拨测与真实用户 | 页面可用性、接口拨测、前端耗时 |
落地顺序
- 先建业务与应用两层，告警才有实际意义
- 再补中间件与基础设施，用于下钻定位
- 最后接体验层，验证用户视角是否真的可用
越靠近业务的指标越适合做告警；越靠近基础设施的指标越适合做定位与容量分析，两类的用途不该互換。
各层缺少统一标签时无法从业务告警下钻到主机，分层反而增加维护成本，只能靠人工对表。