以 ADMQ（Pulsar）为核心场景，统一支持 Kafka、RocketMQ、RabbitMQ、ActiveMQ 等主流消息中间件。在业务受影响前完成容量预警、根因定位与无损扩缩容方案。
当业务增长没有边界，集群容量就成了悬在运维头上的"隐形天花板"。
消息中间件已经成为业务系统的核心基础设施：订单流转、日志采集、异步通知、实时计算、微服务解耦……几乎所有关键链路都依赖它。企业的消息中间件集群里往往同时运行着 ADMQ（Pulsar）、Kafka、RocketMQ、RabbitMQ、ActiveMQ 等多种产品，每种产品的指标口径、监控方式、扩容逻辑都不一样。
随着业务系统不断增加，消息流量、Topic 数量、消费者并发数持续增长。如果没有对存储和流量进行限制，集群迟早会达到饱和。而传统的扩容往往发生在告警之后——也就是业务已经受到影响的时候。
以 ADMQ（Pulsar）集群为例，看看默认配置如何成为业务增长的"隐形天花板"。
某客户核心系统采用 ADMQ（Pulsar）集群承载消息流转，初期按默认模板部署，Broker 节点 JVM 配置为 2g / 2g / 4g（堆内存 2g、元空间 2g、堆外内存 4g）。前期业务流量小，运行平稳。随着业务系统陆续接入，Topic 数量、消息写入量和消费者并发数持续上涨，集群开始偶发写入延迟，部分 Topic 的 backlog 逐渐堆积。
运维团队排查发现：磁盘使用率仅 45%，网络带宽充足；但 Broker JVM 堆内存长期高位运行，元空间接近上限。默认配置未针对业务流量做调整，成为隐形瓶颈。最终只能临时调大 JVM 参数、重启 Broker 止血，期间业务已出现短暂延迟。
Pulsar 看 backlog、Kafka 看 ISR/LAG、RocketMQ 看 consumeLag、RabbitMQ 看 queue depth。指标散落各处，人工统一评估耗时费力，容易遗漏关键风险。
业务增长未对存储和流量设限，消息 retention 默认保留、Topic 无限增长，磁盘、内存、连接数逐步逼近上限，最终在某个夜晚触发连环告警。
JVM 2g / 2g / 4g、默认分区数、默认刷盘策略等出厂配置，适合小流量验证，却扛不住生产环境增长。配置调优需要深厚经验，试错成本高。
容量饱和往往在业务受损后才被发现，运维团队被迫临时救火。扩容决策靠经验，容易出现"扩少了继续爆"或"扩多了浪费"的两难。
传统运维模式下，消息中间件容量管理是"经验 + 告警"的被动模式。要破局，必须让机器先把账算清楚、把趋势画出来、把方案摆出来。
不是替代运维，而是把算趋势、找瓶颈、给方案的工作交给智能体，决策与执行始终由人掌控。
消息中间件扩缩容预测智能体，通过自然语言对话与运维团队协作，背后连接 ADMQ Manager、BBX Agent、集群监控接口和配置管理通道。它能自动采集多中间件指标、计算容量趋势、识别瓶颈根因，并输出可审批的调优建议与扩缩容方案。
智能体将不同中间件的关键指标抽象为统一模型：
无论集群是 Pulsar、Kafka 还是 RocketMQ，运维人员都能通过同一对话入口，获得统一口径的容量视图。
基于历史时序数据，智能体对未来 7 / 15 / 30 天的容量进行预测，并识别最先达到瓶颈的指标：
最终输出每个指标的当前值、预测值、风险等级、预计达到阈值时间，让运维从"凭感觉"变成"看数据"。
智能体不会自动修改生产配置，而是生成建议方案并等待人工审批。例如针对 ADMQ（Pulsar）/消息中间件集群的典型优化方向：
以容量预警与扩缩容为例，智能体把原本数小时的人工排查压缩成六步：
效率、成本、安全、体验——四个维度看得见、算得清的变化。
| 对比项 | 过去（人工模式） | 现在（智能体辅助模式） |
|---|---|---|
| 多中间件观测 | 不同中间件参考不同、手动汇总、口径难齐 | 一屏统一，自动归一化 |
| 容量预警 | 告警即事故，半夜扩容 | 提前 7~30 天预警 |
| 瓶颈定位 | 凭经验排查，试错成本高 | 快速定位根因：存储/内存/吞吐/配置 |
| 参数调优 | 默认配置一刀切，不敢轻易改 | 给出建议方案，人工审批后执行 |
| 扩缩容决策 | 拍脑袋，容易扩多或扩少 | 基于趋势预测，分步无损扩容 |
| 业务影响 | 扩容常伴随停机或抖动 | 优先在线扩容，影响最小化 |
| 问题现象 | 智能体判断 | 建议动作 |
|---|---|---|
| 存储持续增长 | 磁盘使用率趋势 | 扩容磁盘 / 缩短消息保留时间 / 清理过期 Topic |
| 消息堆积（backlog） | 生产 vs 消费能力 | 增加 Consumer / 优化消费逻辑 / 增加分区或队列 |
| JVM 内存高位 | 堆/元空间/堆外内存趋势 | 调大 JVM 内存 / 调整 GC 策略 / 拆分集群 |
| 入流量接近上限 | 吞吐峰值趋势 | 增加 Broker 节点 / 增加分区或 Queue |
| 连接数接近上限 | 连接数趋势 | 增加连接层节点 / 优化客户端连接池 |
一份报表统一展示 ADMQ（Pulsar）、Kafka、RocketMQ 等多中间件的关键指标，告别多平台切换和手工汇总。
基于历史趋势预测未来容量，提前识别磁盘、内存、吞吐、连接等瓶颈，变被动告警为主动预警。
优先给出配置调优建议，必要时给出无损在线扩容方案；所有方案经人工审批后执行，避免影响正常服务。
把"半夜救火"变成"白天规划"，运维团队从疲于应对告警，转向从容管理容量。