除了接口响应时间，我们还需要监控哪些关键指标？—— 一套基于场景的系统健康度检查指南

在构建高可用的分布式系统时，监控报警是保障服务稳定性的最后一道防线。很多开发者容易陷入一个误区：认为监控就是盯着接口响应时间（RT）和错误率。但正如你所提到的，除了这些表层指标，我们需要根据具体的业务场景，深入到系统内部去捕捉那些更隐蔽的风险信号。

以下是我总结的一套针对不同业务场景的关键监控指标体系，希望能为你提供一些实战思路：

1. 数据库连接池：别被“满负荷”欺骗

除了常规的活跃连接数，你必须关注连接池等待率（Connection Pool Wait Rate）和连接泄漏。

• 场景痛点：有时候活跃连接数还没达到上限，但新请求却因为获取不到连接而超时。这就是等待队列积压。
• 核心指标：
  • maxPoolSize 与 activeConnections 的差值。
  • connectionWaitTime：获取连接的平均等待时间。如果这个时间超过 50ms，通常意味着连接池配置过小或 SQL 耗时过长。
  • 泄漏检测：关注连接池的“Created”和“Closed”数量是否长期不匹配。

2. 消息队列（MQ）：积压与消费能力的博弈

消息队列的监控不仅仅是看队列里有多少消息，更要看生产者和消费者的速率匹配。

• 场景痛点：下游服务响应变慢，导致消息处理延迟，最终引发雪崩。
• 核心指标：
  • Consumer Lag（消费滞后量）：这是最重要的指标，表示当前消费位置与最新生产位置的差距。Lag > 0 就是风险。
  • Process Time（单条消息处理耗时）：如果 Lag 在增加，先看是不是消费逻辑变慢了。
  • Dead Letter Queue（死信队列）：死信数量的突增通常意味着序列化异常或数据格式脏数据。

3. 缓存（Redis）：命中率背后的深坑

缓存监控不能只看内存使用率，命中率直接关系到 DB 的负载。

• 场景痛点：缓存穿透或雪崩导致数据库被打挂。
• 核心指标：
  • Cache Hit Ratio（缓存命中率）：通常要求在 95% 以上。如果突然下降，检查是否有大量冷数据访问或缓存失效策略有问题。
  • Evicted Keys（被剔除键数）：如果这个指标在非低峰期飙升，说明内存不足或存在大 Key 问题。
  • Replication Lag（主从延迟）：在读写分离场景下，从节点的数据滞后时间。

4. 业务逻辑层：旁路指标（Side Metrics）

有时候系统本身（CPU、内存）看起来很健康，但业务逻辑卡住了。

• 场景痛点：第三方接口挂了，或者某个异步线程池满了，导致主线程阻塞。
• 核心指标：
  • 第三方 API 调用成功率与 RT：必须将内部监控与外部依赖隔离开。
  • 线程池队列积压：特别是 Tomcat 或业务自定义线程池的 queueSize。
  • 定时任务执行耗时：监控 Batch Job 的执行时间趋势，防止任务堆积。

总结：监控指标选择的“三板斧”

在选择指标时，遵循以下原则：

1. 黄金指标：流量（QPS）、错误率、响应时间、饱和度（队列、线程池）。
2. 业务相关性：指标必须能映射到具体的业务价值（例如：订单创建成功率）。
3. 可行动性：如果一个指标报警了，你必须知道该执行什么操作（扩容、降级、重启）。如果不知道，这个指标就是噪音。

不要盲目监控所有指标，而是要根据你的业务痛点去反推你需要的数据。