监控该看什么：服务器、应用与业务三层指标清单

监控该看什么：服务器、应用与业务三层指标清单

装上监控工具、打开面板，面对满屏的 CPU、内存、吞吐量，很多人会陷入"不知道盯哪个、也不知道多少算异常"的迷茫。这篇文章给你一套判断框架：把指标分成服务器、应用、业务三层，每层只需要盯少量关键指标。搞懂"每个数字意味着什么、多少算危险"，监控才算真正派上用场。

一、三层监控模型：由里到外

把网站想象成一家餐厅：

• 服务器层（厨房）：灶台烧不烧得动、食材够不够——对应 CPU、内存、磁盘、带宽等主机资源；
• 应用层（出餐口）：菜做得快不快、有没有做错——对应请求量、错误率、延迟等应用表现；
• 业务层（收银台）：客人买不买单、回头客多不多——对应注册、转化、订单等业务结果。

三层层层递进：服务器异常多半先反映在应用层，应用异常最终反映在业务层。监控的终点是业务，而不是"数字好看"。

二、服务器层：主机资源四件套

小技巧：CPU、内存、磁盘这些"接近 100% 才危险"的指标，别设太高阈值，要给突发流量留余量；磁盘尤其要早告警，因为磁盘满了往往直接导致服务写不进数据、直接挂掉。完整的指标解读与命令，见Linux 服务器基础指南。除了四件套，还建议盯：负载（load average）、进程数、TCP 连接数（防连接耗尽）。

三、应用层：用 RED 方法论文件夹三个指标

应用层指标多到数不清，业界用一个叫 RED 的口诀收敛到三个核心：

• Rate（请求量）：每秒/每分处理多少请求。用来发现流量突增或突降（可能挂了）。
• Errors（错误率）：失败请求占比，如 4xx/5xx 比例。5xx 率 >1% 就该警觉，>5% 一般要紧急处理。
• Duration（延迟）：请求响应耗时，看 P95/P99 而不是平均值——平均值会被少数慢请求拉平，P99 才是"最慢的 1% 用户"的真实体验。

举个例子：某接口平均延迟 200ms 看着正常，但 P99 是 3 秒，说明有 1% 的用户在忍受明显卡顿。所以监控延迟一定要看分位数。数据库查询慢、第三方调用慢是延迟升高的两大常见来源，排查方法见分布式链路追踪。前端页面性能（首屏、交互）属于另一套指标，见前端性能监控。

四、业务层：让技术指标翻译成商业语言

技术指标正常不代表业务正常。业务层指标因产品而异，常见的有：

• 注册/激活/转化率；
• 订单量、支付成功率、退款率；
• 日活/月活（DAU/MAU）、留存率；
• 客单价、收入。

业务指标一般来自数据库或分析平台（如网站分析设置），比技术指标更难采集，但价值最高：它是判断"监控到底有没有用"的最终标准。比如转化率突然掉一半，技术指标可能完全正常，但业务已经出问题了。

五、指标清单表：直接照抄

落地节奏：刚上手别追求"全指标"。第一周只接服务器四件套 + 应用 RED 五个指标，跑通Prometheus + Grafana 基础或网站监控工具对比里的任一方案；第二个月再逐步加业务指标和告警。

六、常见问题

Q1：指标太多，面板放不下怎么办？
分层管理：服务器层、应用层、业务层各一个面板；每层只放"会行动的指标"。看板是给人看的，不是数据堆砌。工具选择可参考云监控服务对比。

Q2：平均值和分位数到底看哪个？
延迟、响应时间这类"体验"指标看分位数（P95/P99）；容量类指标（磁盘、内存）看当前值和趋势。平均值容易掩盖真实问题，别做"被平均的人"。

Q3：业务指标太难采，可以不做吗？
至少做一两个最核心的（如订单量、转化率）。没有业务指标的监控，等于"发动机正常，但不知道车有没有到目的地"。可以先从简单的定时查询数据库计数开始。

Q4：更多监控相关内容去哪看？
本站监控报警分类下有监控搭建、告警设计、SLO 等完整体系，可与本文化为一条学习路径。