监控核心关注的指标
一、业务层指标（最核心，直接反映用户体验）
业务指标是监控的 “最终落脚点”，直接体现用户是否能正常使用服务，需与具体业务场景强绑定。
- 核心业务指标（按场景举例）
电商 / 交易场景：
订单成功率（下单数 / 支付成功数，核心指标，直接关联营收）；
支付成功率（发起支付数 / 支付完成数，支付链路是否通畅）；
商品搜索成功率（搜索请求数 / 返回结果数，用户能否找到商品）。
社交 / 内容场景：
消息送达率（发送消息数 / 接收成功数，核心功能可用性）；
内容加载成功率（请求内容数 / 加载完成数，用户能否看到内容）；
登录成功率（登录请求数 / 登录成功数，用户能否进入系统）。 - 通用业务健康指标
**业务量（QPS/TPS）：**每秒请求数 / 交易数（反映业务活跃度，突增 / 突降可能是异常）；
响应时间（RT）：用户操作到收到结果的耗时（如页面加载时间、接口响应时间，直接影响体验，需关注 P50/P95/P99 分位值，避免被平均掩盖长尾延迟）；
错误率：失败请求数 / 总请求数（如 HTTP 5xx 错误占比、业务逻辑错误占比，超过阈值说明服务异常）。
环比/同比量级波动、跌0
二、应用层指标（服务端代码 / 接口的运行状态）
应用层是业务的 “执行载体”，指标反映代码逻辑、接口调用是否正常。 - 接口 / API 指标
接口成功率：成功响应数 / 总请求数（需按接口粒度监控，核心接口（如支付）需达到 99.99% 以上）；
接口响应时间：接口处理请求的耗时（分接口统计，关注 P95/P99，避免个别慢请求影响整体体验）；
接口调用量：各接口的 QPS（突增可能是异常流量，突降可能是上游服务故障）。 - 应用内部指标
线程池状态：活跃线程数、队列等待数、拒绝数（线程池满会导致请求被拒，是应用崩溃的前兆）；
JVM / 内存指标（针对 Java 应用）：
堆内存使用率（持续升高可能内存泄漏）；
GC 频率与耗时（Full GC 频繁或耗时过长会导致应用卡顿）；
异常数：未捕获异常、自定义业务异常的发生频率（突然增多说明代码逻辑有问题）。
三、基础设施层指标（服务器、数据库、中间件等支撑组件）
基础设施是应用的 “运行环境”，指标反映资源是否充足、组件是否健康。 - 服务器 / 虚拟机指标
CPU 使用率：用户态 + 系统态占比（持续 > 80% 可能导致应用响应慢，需区分 “业务进程占用” 还是 “系统进程异常占用”）；
内存使用率：已用内存 / 总内存（避免 OOM，需关注 “可用内存” 而非 “已用占比”，因为缓存内存可释放）；
磁盘 I/O：读写吞吐量、IOPS（磁盘满或 I/O 阻塞会导致应用读写文件 / 日志变慢，数据库尤其敏感）；
网络带宽：入网 / 出网流量（突增可能是被攻击或异常请求，带宽占满会导致服务不可达）。 - 数据库指标
连接数：当前连接数 / 最大连接数（连接数满会导致新请求无法连接数据库）；
查询性能：慢查询次数、平均查询耗时（慢查询过多会拖垮数据库，需及时优化）；
锁状态：表锁 / 行锁等待数、锁等待时间（锁竞争激烈会导致事务阻塞，影响并发能力）；
主从同步延迟：从库落后主库的时间（延迟过高会导致读写分离场景下数据不一致）。 - 中间件指标（缓存、消息队列等）
Redis 缓存：
内存使用率（满了会触发淘汰策略，影响缓存命中率）；
命中率（命中数 / 总请求数，过低说明缓存失效或设计不合理，会穿透到数据库）；
连接数、响应时间（同数据库逻辑，连接满或响应慢会影响应用）。
消息队列（如 Kafka/RabbitMQ）：
队列堆积量（消息生产速度 > 消费速度，堆积过多会导致延迟增长，甚至磁盘占满）；
消费成功率（失败消息数 / 总消息数，失败过多可能是消费者逻辑错误）；
分区 / 节点健康状态（是否有分区不可用、副本同步异常）。
总结：核心指标的选择原则
业务优先：所有指标最终要能关联到 “用户体验” 或 “业务损失”（如 “CPU 高” 本身不重要，重要的是 “CPU 高导致订单成功率下降”）；
聚焦核心：只监控 “影响系统可用性的关键指标”（如核心接口成功率、数据库连接数），避免冗余（如非核心服务器的 “开机时长” 无需监控）；
可量化、可告警：指标需有明确阈值（如 “错误率> 1% 告警”），且能被监控系统采集和计算；
分层联动：指标需形成链路（如用户端延迟升高→应用接口响应慢→数据库慢查询→磁盘 I/O 阻塞），便于定位根因。