监控消息中间件吞吐量关键在于匹配生产、传输、消费三环节速率，并识别早于业务告警的异常波动；需采集Messages/Bytes In/Out Per Sec、端到端TPS等指标，用kafka_exporter等专用Exporter高效采集，结合动态基线与失败率关联告警，并在Grafana中对齐展示生产TPS、消费TPS与Lag曲线。
监控消息中间件吞吐量，关键不是“看数字”，而是看清生产、传输、消费三个环节的速率是否匹配，以及异常波动是否早于业务告警出现。
吞吐量指标要盯紧这三类核心数据
不同中间件指标命名不同，但逻辑一致：看“单位时间成功流转的消息量”。重点采集：
-
Messages In/Out Per Sec：Broker每秒接收/投递的消息数（Kafka 的
MessagesInPerSec、RocketMQ 的msgPutTotalTps/msgGetTotalTps），反映整体负载能力 -
Bytes In/Out Per Sec：网络带宽压力指标（如 Kafka 的
BytesInPerSec），大消息场景下比消息数更能暴露瓶颈 -
Producer/Consumer TPS：端到端视角，比如 Kafka Producer 的
record-send-rate、RocketMQ Consumer 的pullTps，可定位是发不出去还是拉不动
用 Prometheus 链路高效采集（推荐方案）
不建议直接抓 JMX（开销大、延迟高），优先用专有 Exporter：
- Kafka：部署
kafka_exporter，自动连接所有 Broker，暴露kafka_topic_partition_current_offset、kafka_consumergroup_current_offset等原生指标，秒级采集 - RocketMQ：启用 Proxy 的 OpenTelemetry，或通过
rocketmq_client_tps、rocketmq_broker_tps等指标聚合计算吞吐 - RabbitMQ：用
rabbitmq_exporter，关注rabbitmq_queue_messages_ready和rabbitmq_queue_messages_unacknowledged的变化速率，反推实际消费吞吐
告警不能只设固定阈值
吞吐量天然有业务周期性（如早晚高峰），固定阈值容易误报。建议：
- 按业务基线动态计算：比如过去7天同时间段的 P90 值 × 1.5 作为高水位，连续5分钟超限才触发
- 关注“断崖式下跌”：吞吐量 2 分钟内下降超 60%，往往预示 Producer 异常或网络中断
- 关联失败率：
FailedProduceRequestsPerSec > 0.5持续 2 分钟，比吞吐下降更早暴露问题
可视化必须体现链路关系
单看总吞吐没意义，要和下游消费能力对齐：
- 在 Grafana 看板中并列展示：生产 TPS、消费 TPS、当前 Lag（堆积量） 三条曲线
- 加一个“吞吐差值 = 生产 TPS − 消费 TPS”，正向持续扩大说明消费跟不上，负向则可能生产端抖动
- 按 Topic 或 Consumer Group 下钻，快速定位是全局问题还是局部瓶颈
