消息队列监控与容量规划
消息队列的稳定性要靠监控消费堆积、生产速率、消费速率、Broker 磁盘、分区热点和失败消息。
消息队列监控与容量规划
消息队列上线后，最常见的生产问题不是“不能发送消息”，而是“消息开始堆积，但没人及时发现”。
监控和容量规划是 MQ 生产化的核心部分。
Rendering diagram...
核心指标
生产端要看发送 QPS、发送延迟、发送失败率、重试次数。
Broker 要看磁盘使用率、网络吞吐、请求延迟、副本同步状态、Topic 分区分布。
消费端要看消费 QPS、处理延迟、失败率、重试次数、Consumer Lag。
Consumer Lag
Consumer Lag 表示消费者落后生产者多少消息。
如果 Lag 持续增长，说明消费能力不足或消费者异常。
lag = latest_offset - committed_offset
Lag 短时间上升不一定是问题，但持续上升必须告警。
容量规划
容量规划要估算：
- 峰值写入 QPS。
- 单条消息大小。
- 保留时间。
- 副本数。
- 消费者数量。
- 分区数量。
- 磁盘增长速度。
Kafka 的磁盘容量可以粗略估算：
daily_bytes = qps * avg_message_size * 86400
storage = daily_bytes * retention_days * replication_factor
分区热点
如果 key 分布不均，某些 Partition 可能流量特别高，导致单分区堆积。
常见原因是使用了低基数字段作为 key，比如 status、country。更适合用订单 ID、用户 ID、设备 ID 等高基数字段。
告警建议
至少要对这些情况告警：
- Consumer Lag 持续增长。
- 消费失败率升高。
- 死信数量增加。
- Broker 磁盘超过阈值。
- 副本不同步。
- 生产失败率升高。
小结
消息队列不是部署完就结束。真正稳定的 MQ 系统，一定有清晰的监控、告警、容量规划和扩容预案。